(19) 



J 



(12) 



EuropSisches Patentamt 
European Patent Office 
Office europ&sn des brevets (11) EP 0 720 089 A1 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

03.07.1996 Bulletin 1996/27 

(21) Application number: 95119049.5 

(22) Date of filing: 04.12.1995 



(51) Int. CI 6 : G06F 9/44, G06F 3/033 



(84) Designated Contracting States: 


• Johnson, William Jesse 


DE FR GB 


Flower Mound, Texas 75028 (US) 




• Williams, Marvin L. 


(30) Priority: 30.12.1994 US 366531 


Arlington, Texas 76017 (US) 


(71) Applicant: International Business Machines 


(74) Representative: Rach, Werner, Dr. 


Corporation 


IBM Deutschland 


Armonk, N.Y. 10504 (US) 


Informationssysteme GmbH, 




Patentwesen und Urheberrecht 


(72) Inventors: 


70548 Stuttgart (DE) 


• Johnson, Sophia M. 




Rower Mound, Texas 75028 (US) 





(54) Method and system for recalling desktop states In a data processing system 



(57) A method and system are disclosed for recalling 
a previous desktop state of a data processing system, 
where a desktop state specifies a dependence hierarchy 
and visual arrangement of a number of graphical objects 
representative of operating system functions and data 
processing applications that are displayed within a dis- 
play device of the data processing system. The system 
of the present invention detects each occurrence of a 
desktop event which creates a new desktop state. In 
response to detecting an occurrence of a desktop event, 
the system records the new desktop state. In response 
to a particular user input, the system automatically 
returns the desktop to a selected state previous to the 
current desktop state by referencing the recorded desk- 
top states, wherein all operating system functions and 
data processing applications available at the selected 
state are enabled. 
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Description 

BACKGROUND OF THE INVENTION 

Technical Field 

The present invention relates in general to a method 
and system for improved data processing and in partic- 
ular to a method and system for manipulating desktop 
objects displayed within the display device of a data 
processing system. Still more particularly, the present 
invention relates to a method and system for recalling 
previous desktop states while preserving all functions 
available within the resulting context. 

Description of the Related Art 

A Graphical User Interface (GUI) is a well-known 
technique of presenting information to a user of a data 
processing system in a graphical and intuitive manner. 
Typically, a user is presented with a number of desktop 
objects, such as data processing applications, system 
functions or data files, which the user may select utilizing 
a graphical pointing device or other input means, such 
as voice, keyboard, or touch screen. Once the user has 
selected a desktop object, the user may reposition the 
selected desktop object, also known as the focused 
object, within the display screen utilizing the familiar 
drag-and-drop technique. Alternately, if the focused 
object represents a software module, the user may 
invoke the execution of the software module by manipu- 
lating the focused object in a manner dependent upon 
the operating system environment. 

Although a GUI provides an easily utilized interface 
to a data processing system, a GUI is often inefficient 
since a user may have to perform several manipulations 
of desktop objects to return to a previous desktop state. 
For example, after system power-on, a user may be pre- 
sented with a desktop manager menu. By selecting items 
within the desktop manager menu a user may spawn a 
main menu containing a number of data processing 
applications or operating system functions. The user 
may then manipulate the graphical objects representing 
the applications or system functions to relocate them 
within the display or to spawn the applications or func- 
tions themselves. Thus, a user may, for example, double- 
click with a mouse on a first application icon to spawn 
application A. The user may then open a window X within 
application A and process data. Thereafter, the user may 
spawn application B while within window X and then 
close window X, thereby removing window X from the 
desktop. After several similar manipulations, the user 
may wish to return the desktop to the state in which win- 
dow X of application A was open and active on the desk- 
top. 

Many data processing applications provide features 
that enable a user to retrace prior processing paths. On 
such feature, commonly referred to as "undo," enables a 
user to incrementally reverse processing steps per- 



formed within a data processing application. Conceptu- 
ally, an undo function chronologically stores processing 
steps in a stack. Each invocation of the undo function 
returns the application to the immediately previous state, 

5 thereby enabling a user to navigate to any previous state 
for which dependent paths have not been destroyed. For 
example, a user manipulating graphical objects within a 
drawing application may return a graphical object to a 
previous location by invoking the application's undo func- 

70 tion. However, undo functions are limited to a specific 
application and to contexts within that application. A 
desktop environment may require intermediate process- 
ing steps to return to a previous desktop state that may 
have been destroyed by subsequent manipulation of 

75 desktop objects. For example, in the desktop example 
described above, window X was destroyed (i.e., removed 
from the desktop) after the user branched to a dependent 
path by invoking application B. 

A record/playback function or macro is a second 

20 type of feature commonly available in data processing 
systems which enables a user to automatically re-per- 
form previously executed processing steps. To utilize a 
record/playback function, a user typically instructs the 
system to begin recording and then enters a series of 

25 inputs. After entering the desired inputs, the user 
instructs the system to stop recording. When the user 
desires to enter the recorded series of inputs to the sys- 
tem, the user instructs the system to replay the recorded 
inputs in lieu of the user reentering the inputs utilizing a 

30 keyboard or mouse, for example. Some data processing 
systems provide a similar feature which enables a user 
to program keys on the keyboard to represent a user- 
defined series of keystrokes. A record/playback function 
or programmed keys may be utilized within either an 

35 application or in a desktop operating environment. How- 
ever, a record/playback feature and programmed keys 
do not enable a user to return to previous desktop state, 
but merely to repeat a pre-defined series of inputs. Fur- 
thermore, a user must often navigate to a starting point 

40 prior to playback. Consequently, in currently available 
data processing systems, to return to a previous desktop 
state a user must return the desktop to a state anteced- 
ent to the desired state and re-perform the desktop 
object manipulations required to arrive at the desired 

45 state. 

Therefore, it would be desirable to provide a method 
and system for automatically recalling previous states of 
the desktop which preserve all functions available within 
the resulting context. 

so 

SUMMARY OF THE INVENTION 

ft is therefore one object of the present invention to 
provide an improved method and system for data 
55 processing. 

ft is another object of the present invention to provide 
an improved method and system for manipulating desk- 
top objects displayed within the display device of a data 
processing system. 
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It is yet another object of the present invention to pro- 
vide an improved method and system for recalling previ- 
ous desktop states while preserving all functions 
available within the resulting context. 

The foregoing objects are achieved as is now 
described. A method and system are disclosed for recall- 
ing a previous desktop state of a data processing sys- 
tem, where a desktop state specifies a dependence 
hierarchy and visual arrangement of a number of graph- 
ical objects representative of operating system functions 
and data processing applications that are displayed 
within a display device of the data processing system. 
The system of the present invention detects each occur- 
rence of a desktop event which creates a new desktop 
state. In response to detecting an occurrence of a desk- 
top event, the system records the new desktop state. In 
response to a particular user input, the system automat- 
ically returns the desktop to a selected state previous to 
the current desktop state by referencing the recorded 
desktop states, wherein all operating system functions 
and data processing applications available at the 
selected state are enabled. 

The above as well as additional objectives, features, 
and advantages of the present invention will become 
apparent in the following detailed written description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The inven- 
tion itself, however, as well as a preferred mode of use, 
further objectives and advantages thereof, will best be 
understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

Figure 1 illustrates a data processing system utiliz- 
ing the method and system of the present 
invention; 

Figure 2 depicts a preferred embodiment of a data 
structure utilized to store a hierarchy of 
desktop objects according to the present 
invention; 

Figure 3 illustrates a preferred embodiment of the 
structure of an entry within the data struc- 
ture depicted in Figure 2; 

Figure 4 depicts a flowchart of the process utilized 
by the present invention to build and main- 
tain the data structure depicted in Rgure 2; 
and 

Figure 5 illustrates a flowchart of the process utilized 
by the present invention to recall previous 
desktop states. 



DETAILED DESCRIPTION OF PREFERRED EMBOD- 
IMENT 

With reference now to the figures and in particular 

5 with reference to Rgure 1, there is illustrated a data 
processing system employing the method and system of 
the present invention. As illustrated, data processing 
system 10 includes processing unit 12, display device 
14, keyboard 16, and mouse 18. Typically, processing 

10 unit 12 includes a processor, a memory, and interface 
adaptors to interface peripheral devices such as key- 
board 16 and mouse 18, as well as other peripherals 
such as a local printer (not illustrated). 

As is well-known in the art, a user may input data to 

is processing unit 12 utilizing keyboard 16 or mouse 18. 
Typically, input from keyboard 16 generates an interrupt 
that invokes the execution of a keyboard interrupt han- 
dler within the processor of processing unit 1 2. Input from 
mouse 1 8 is received by a peripheral device driver within 

20 processing unit 12. Like input from keyboard 16, each 
movement of mouse 1 8 generates an interrupt. The input 
signals from mouse 1 8, known in the art as mouse "drop- 
pings," are utilized by the GUI software executing within 
the processor of processing unit 12 to relocate or to 

25 select graphical objects displayed within display device 
14. Both the keyboard and mouse input signals are 
accessible prior to processing by the processor through 
the use of software "hooks" which intercept the signals 
for use in other processes executing within the proces- 

30 sor. 

Processing unit 12 outputs data to a user in visual 
format via display device 14. According to the present 
invention, output data from processing unit 12 is pre- 
sented to a user through a graphical user interface (GUI), 

35 which presents data to a user in a graphical and intuitive 
manner. As is well-known in the art, in systems utilizing 
a GUI, the operating system or GUI application displays 
a desktop to a user, which forms the root of a hierarchy 
of graphical objects displayed within the display device. 

40 On the desktop, the GUI may display a number of menu 
options and graphical objects, such as application icons, 
which form a second level within the hierarchy. Utilizing 
keyboard 16 or mouse 18, a user may invoke operating 
system functions or data processing applications via 

45 pull-down menu or icon selections. The invocation of an 
application or system function may in turn cause the GUI 
to display dependent graphical objects such as windows 
or decision boxes on the desktop, which form lower levels 
within the desktop object hierarchy. 

so Referring now to Rgure 2, there is depicted a rep- 
resentation of a preferred embodiment of a data struc- 
ture utilized by the present invention to store the 
hierarchy of desktop objects. Object dependency table 
(ODT) 20 comprises n entries, each corresponding to a 

55 distinct desktop state, wherein a desktop state includes 
the presence and position of desktop objects, as well as 
the identity of a focused object. As will be appreciated 
by those skilled in the art, n is variable and depends upon 
the current number of desktop objects as well as the 
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manipulation history of the current desktop objects. 
Although the total number of entries within ODT 20 is 
potentially infinite, n is limited by design choice to a max- 
imum number of states which a user desires to be able 
to recall. Should the number of entries reach the imple- 
mented limit, new entries are inserted into ODT 20 in 
place of the least recently inserted entries. As will be 
described with reference to Figure 4, ODT 20 is 
arranged chronologically, with one entry inserted for 
each new desktop state. 

With reference now to Figure 3, there is illustrated 
a representation of a preferred embodiment of an entry 
within ODT 20. The five fields 32-40 within entry 30 
reflect a preferred embodiment of the present invention 
employed within a data processing system utilizing a 
OS/2 operating system and Presentation Manager GUI 
software. Those skilled in the art will appreciate that in 
data processing systems utilizing other operating sys- 
tems and GUI software the structure of entry 30 may dif- 
fer. 

The first two fields of entry 30, object title bar text 
(TBT) 32 and object class (OC) 34, together comprise a 
unique object identifier in systems utilizing Presentation 
Manager in an OS/2 operating environment. In other 
embodiments, the unique object identifier stored in fields 
32 and 34 may comprise a single unique key or combi- 
nation of keys which specify a unique handle to an object 
within a data processing system. In the depicted embod- 
iment, TBT 32 stores the text displayed on the title bar in 
conjunction with the focused object associated with entry 
30. OC 34 specifies the Presentation Manager class to 
which the associated focused object belongs. 

Next, object dependency (OD) field 36 indicates the 
relationship of the object associated with entry 30 to 
other objects within the graphical object hierarchy. If 
entry 30 is associated with the desktop itself, which in all 
cases is the root node of the desktop object hierarchy, 
OD 36 will indicate that the dependency is "none". If. 
however, the associated object is a first-level object (e.g., 
an icon or menu selection), OD 36 will indicate that the 
entry's associated object is dependent upon the "desk- 
top" in the desktop object hierarchy. If entry 30 is asso- 
ciated with a new desktop object that is not a first-level 
object, OD 36 will identify the parent object by unique 
object identifier, which in the depicted embodiment is the 
TBT and OC of the parent object. Finally, as will be 
described further below, if entry 30 (corresponding to a 
new desktop state) is created by an input from keyboard 
16, mouse 18, or other peripheral device that does not 
spawn a new desktop object, OD 36 will specify that entry 
30 is a "continuation," indicating that the new desktop 
state is associated with the desktop object associated 
with the preceding desktop state. 

The next field, invocation sequence (IS) 38, indi- 
cates how entry 30 was generated. If OD 36 specifies 
that the state is a "continuation," IS 38 will list the key- 
strokes, menu selections, button activations or other 
inputs tracked by the presentation Manager utilized to 
generate entry 30. However, if OD 36 has a value other 



than "continuation", IS 38 will indicate the invocation 
which derived the graphical object associated with entry 
30 from its associated parent object. As described 
above, the present invention detects the invocation 
5 sequence associated with a new state by utilizing soft- 
ware hooks which intercept and log all traceable pro- 
grams, functions and system application programming 
interface (API) calls generated by a manipulation of a 
desktop object. Manipulations of a desktop object that 
w create a new desktop state include input to the object, 
moving, sizing, minimizing, or maximizing the object, 
invoking or terminating the object, and any other manip- 
ulation that can be performed on an object. 

Finally, entry 30 includes status bits 40. In the pre- 
15 ferred embodiment discussed with reference to Figures 
4 and 5, only a single status bit is utilized to indicate if 
entry 30 may be deleted from ODT 20. In other embod- 
iments of the present invention, additional status bits 
may be utilized to enhance performance. For example, 
an additional status bit may be utilized to indicate if the 
associated object is currently focused. The addition of 
the focus bit would enable the process of the present 
invention to determine if an object is focused by exam- 
ining a status bit rather than scanning Presentation Man- 
ger records. Similarly, in other embodiments status bits 
40 may include a bit indicative of whether the associated 
object is active on the desktop (i.e., minimized or maxi- 
mized on the desktop). Those skilled in the art will appre- 
ciate that additional status bits, although useful, increase 
the processing overhead required to maintain and utilize 
ODT 20. 

Referring now to Figure 4, there is depicted a flow- 
chart of the process utilized by the present invention to 
build and maintain object dependency table (ODT) 20. 
The depicted process may be implemented by suitable 
software executing within data processing system 10 
and may be automatically started upon system startup. 
As illustrated, the process begins at block 50, and there- 
after proceeds to block 52, which illustrates inserting a 
root entry into ODT 20 representing the desktop. The 
fields within the first entry indicate that the object is of 
the class "desktop", that the title bar text displayed is 
"null", that the desktop is not dependent upon other 
objects, and that the desktop is invoked by the keystroke 
sequence (CtlxAltxDel) (i.e., system reset). Next, the 
process proceeds to block 54, which depicts the process 
detecting input which manipulates the focused object of 
the current desktop state. The process of the present 
invention intercepts all inputs to the Presentation Man- 
ager logged by the device driver hooks, presentation 
manager hooks, and operating system hooks which 
change the state of the desktop. These inputs include 
keyboard interrupts, mouse droppings, and application 
programming interface (API) instructions. 

After an input is received, the process proceeds to 
block 56, which illustrates determining if the history recall 
function of the present invention was invoked. In a pre- 
ferred embodiment of the present invention, the history 
recall function is invoked by pressing a pre-defined func- 
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iion key on keyboard 16; however, those skilled in the art 
will appreciate that many combinations of inputs, includ- 
ing keystroke sequences, mouse selections, or other 
inputs, may be utilized to invoke the history recall func- 
tion of the present invention, rf the history recall function 5 
was invoked, the process proceeds to block 58, which 
depicts sending a message to the control process inter- 
rupt thread of the present invention depicted in Figure 5 
which is dedicated to recalling previous desktop states. 
In a preferred embodiment of the present invention, invo- w 
cation messages are communicated to the interrupt con- 
trol process depicted in Figure 5 via a work queue stored 
in the memory of processing unit 12. The work queue 
consists of a number of memory locations initialized to a 
predetermined value. When a user invokes the history 15 
recall function of the present invention, one of the entries 
in the work queue is written with a second value to signify 
that the history recall function was invoked. As will be 
described with reference to Figures, the desktop history 
recall function of the present invention is executed once 20 
for each message within the work queue. Although a pre- 
ferred embodiment of the present invention utilizes a 
memory queue to communicate between the processes 
depicted in Figures 4 and 5, those skilled in the art will 
appreciate that a number of known methods of commu- 2 s 
nicating between concurrently executing asynchronous 
processes may be utilized. Ideally, the work queue may 
contain an infinite number of entries. However, those 
skilled in the art will appreciate that the work queue may 
be limited to a maximum number of entries. Should the 30 
number of invocations of the history-recall function 
exceed the implemented limit, an audible beep or other 
notification is presented to the user indicating that the 
maximum number of history recall iterations are pending. 
From block 58, the process returns to block 54, which 35 
has been described. 

Returning to block 56, if the input received was not 
an invocation of the history recall function, the process 
proceeds to block 60 which determines if the input was 
a request to terminate the history recall process. If so, ao 
the process proceeds to block 62, which illustrates ter- 
minating the history recall process and purging all mes- 
sages from the work queue. Thereafter, the process 
terminates at block 64. 

If the input received was neither an invocation of the as 
history recall function nor a termination request, the 
process proceeds to block 66, which depicts deleting all 
entries within ODT 20 which have no dependent ODT 
entries and which have been marked for deletion by set- 
ting a bit within status bits 40. In a preferred embodiment so 
of the present invention, the step illustrated at block 66 
is implemented as a subroutine which recursively scans 
ODT 20 for entries marked for deletion whose associated 
desktop object is not identified within OD 36 of any other 
entry as the parent of the entry's associated object. ss 

Next, the process proceeds to block 68, which 
depicts determining if the input detected at block 54 
caused the destroy (i.e., the removal from the desktop) 
of an object. If not, the process then proceeds to block 



70, which determines if the input caused the spawning 
of an object on the desktop. rf the input caused neither 
the spawning nor the destroy of a desktop object, the 
process proceeds to block 72, which illustrates inserting 
an entry into ODT 20. The fields within the inserted entry 
indicate the unique object identifier of the focused object, 
that the object dependency is a continuation, and the 
user or system interaction which generated the new 
desktop state. For example, block 72 would be per- 
formed by the process when a user types a character 
utilizing keyboard 16 which does not spawn or destroy a 
desktop object. Thereafter, the process returns to block 
54. In an alternative embodiment, block 72 could update 
an existing entry within ODT 20 if the most recently 
inserted entry within ODT 20 is marked as a continua- 
tion. In this case, block 72 would append the invocation 
sequence of the current desktop state to that stored 
within the most recently inserted entry within ODT 20, 
thereby reducing the storage required for ODT 20. In this 
alternative embodiment, the history recall process 
depicted in Figure 5 would be restructured to process 
entries storing multiple invocation sequences within a 
single entry within ODT 20. 

Returning to block 70, if the input caused the spawn- 
ing of a desktop object, the process proceeds to block 
74. Block 74 illustrates inserting an entry into ODT 20 
specifying the unique object identifier of the spawned 
object, the object which spawned the current object, and 
the invocation sequence which spawned the new desk- 
top object. Thereafter, the process returns to block 54. 

Returning to block 68, if the input caused the destroy 
of an object, the process proceeds to block 76, which 
depicts marking the object and its associated continua- 
tion entries for deletion. Next, the process proceeds to 
block 78, which determines if other entries within ODT 
20 depend on the destroyed object. If so, the process 
returns to block 54 without deleting the destroyed object. 
The object is not deleted immediately since subsequent 
invocations of the history recall function may require 
recalling the destroyed object in order to recall desktop 
states subsequent to the destruction of the object. If, 
however, no entries within ODT 20 depend on the 
destroyed object, the process proceeds to block 80, 
which illustrates deleting all entries within ODT 20 which 
are marked for deletion and which have no dependent 
entries. Thereafter, the process returns to block 54. 

With reference now to Figure 5, there is illustrated 
a flowchart of the process utilized by the present inven- 
tion to recall previous desktop states. The process 
depicted in Figure 5 comprises an asynchronous thread 
that may be implemented by suitable software executed 
within data processing system 10. The process begins 
at block 1 00, and thereafter proceeds to block 1 02, which 
depicts detecting a message from the monitoring proc- 
ess depicted in Figure 4 indicating that the history recall 
function has been invoked. Detection is implied by suc- 
cessfully reading an entry from the work queue. Block 
1 02 remains idle until a work queue entry becomes avail- 
able. The process then proceeds to Nock 104, which 
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illustrates terminating the monitoring process illustrated 
in Figure 4. The monitoring process of Figure 4 is sus- 
pended until the completion of the process of Figure 5 
since by invoking the history recall function, a user indi- 
cates that further manipulations of desktop objects within 
the current context are not desired. Those skilled in the 
art will appreciate that the processes depicted in Figures 
4 and 5 will execute quickly given sufficient hardware and 
only in unusual circumstances would a user be unable 
to navigate without undue delay. Next, the process pro- 
ceeds to block 106, which illustrates disabling the updat- 
ing of the display. In a preferred embodiment of the 
present invention in which the process is operating with 
an OS/2 environment, block 106 is performed by the 
operating system command "WinenableWindow(DESK- 
TOPFALSE)" which prevents screen refreshes until the 
command is repeated. Those skilled in the art will appre- 
ciate that in other embodiments of the present invention 
executing in other operating system environments, the 
updating of the display may be similarly disabled utilizing 
other commands. 

Thereafter, the process proceeds to block 108, 
which depicts setting two variables, current TBT and cur- 
rent OC, to the values stored in the most recently 
inserted ODT entry corresponding to the current desktop 
state. The process then retrieves from ODT 20 the most 
recently inserted entry matching the current TBT and 
current OC values. Next, the process proceeds to block 
110, which illustrates marking the most recently inserted 
ODT entry matching current TBT and current OC for 
deletion by setting a status bit. The process then pro- 
ceeds to block 112, which illustrates retrieving from ODT 
20 the most recently inserted entry having an object 
dependency which is not a continuation and which 
matches the unique object identifier specified by current 
TBT and current OC. This desktop state is known as an 
anchor state. The process then proceeds to block 114, 
which illustrates storing in a last-in, first-out (LIFO) queue 
the invocation sequence of the anchor state retrieved at 
block 112 and the invocation sequences of all following 
entries which have a continuation object dependency 
upon the retrieved entry. Depending upon the manipula- 
tion history of the object associated with the retrieved 
entry, there may or may not be continuation ODT entries. 
Thereafter, the process proceeds to block 116, which 
depicts deleting all entries within ODT 20 which are 
marked for deletion that have no dependent entries. The 
function performed at block 116 may be implemented by 
the same software routine utilized to perform blocks 66 
and 80 of Figure 4. 

The process then proceeds to block 118, which 
determines if the graphical object associated with the 
ODT entry retrieved at block 112 is dependent upon 
another object within ODT 20. If not, the retrieved object 
is the first entry within ODT 20, namely, the desktop. 
Therefore, the process proceeds to block 1 24 which illus- 
trates rebooting the system since the desktop is invoked 
by the keystroke sequence (CtrlxAltxDel). After waiting for 
startup to complete at block 126, the process proceeds 



to block 130, which depicts issuing all invocation 
sequences stored in the LIFO queue, except for the last 
which is discarded. Thus, the process automatically 
inputs all commands required to return the desktop to 

5 the state immediately previous to the current state. The 
invocation sequences stored in the LIFO queue are exe- 
cuted in the correct order since ODT 20 is scanned in 
reverse chronological order and the invocation 
sequences are executed in LIFO order. In general, a user 

io would not wish to cause block 1 24 and following process- 
ing steps to execute since the same result could be 
obtained by simply rebooting the system. 

The process then proceeds to block 1 34, which illus- 
trates determining if the work queue contains additional 

is entries. The work queue will contain additional entries if 
a user invoked the history recall function multiple times 
by pressing a function key several times in succession, 
for example. Those skilled in the art will appreciate that 
the history recall function of the present invention may 

20 be implemented so that a user can input a desired recall 
depth without inputting a keystroke for each desired level 
of recall. In that case, the recall depth would correspond 
to the number of iterations performed of the loop com- 
posed of blocks 108-132. If additional invocations of the 

25 history recall functions are indicated by messages within 
the work queue, the process removes the current entry 
from the work queue at block 136, and then returns to 
block 108 to process the additional work queue entries, 
rf, however, no entries were present in the work 

30 queue at block 1 34, the process proceeds to block 1 38. 
Block 1 38 depicts enabling screen updates, for example, 
by sending a message to the operating system. In the 
preferred embodiment of the present invention in which 
the process is operating within an OS/2 environment, 

35 block 138 is performed by executing the operating sys- 
tem command "WinenableWindow(DESKTOPTRUE) n 
which enables screen refreshes. Thereafter, the screen 
is refreshed at block 140 and the monitoring process 
illustrated in Figure4 is enabled at block 142. Thereafter, 

40 the process returns to block 1 02 to process further invo- 
cations of the history recall function. 

Returning to block 1 18, if the ODT entry retrieved at 
block 1 1 2 is dependent upon another desktop object, as 
is the usual case, the process proceeds to block 120. 

45 Block 1 20 illustrates determining if the parent object (i.e. , 
the graphical object associated with the anchor state) is 
present on the desktop. If not, the process proceeds to 
block 122, which illustrates updating current TBT and 
current OC to the values of the parent of the retrieved 

so ODT entry. The process then returns to block 112. The 
process repeats blocks 1 1 2-1 22 until the process locates 
a parent graphical object present on the desktop. The 
process is guaranteed to find a present parent since the 
desktop itself is always present. When a present parent 

55 is located at block 1 20, the desired anchor state is found 
and the process proceeds to block 128. Block 128 illus- 
trates popping the parent object into focus. Thereafter, 
the process proceeds to block 130 and following blocks 
which have been described. 



6 



11 



EP 0 720 089 A1 



12 



As has been described the present invention pro- 
vides a method and system for recalling previous states 
of a desktop displayed within the display device of a data 
processing system. The present invention enables a 
user to efficiently return to previous states of the desktop 
without re-performing the desktop object manipulations 
required to return to the previous state. In addition, since 
the present invention reexecutes the invocation 
sequences precedent to the desired context beginning 
with an anchor state corresponding to an object present 
on the desktop, all functions available at the desired con- 
text are enabled. 

Claims 

1 . A method within a data processing system for recall- 
ing a previous desktop state, wherein a desktop 
state comprises a dependence hierarchy and visual 
arrangement of a plurality of graphical objects rep- 
resentative of operating system functions and data 
processing applications that are displayed within a 
display device of said data processing system at a 
specified time, said method comprising: 
detecting each occurrence of a desktop event, which 
creates a new desktop state; 

in response to detecting an occurrence of a desktop 
event, recording said new desktop state; and 
in response to a particular input from a user, auto- 
matically returning said desktop state to a selected 
state which occurred prior to a current desktop state 
by referencing said recorded desktop states, 
wherein all operating system functions and data 
processing applications available at said selected 
state are enabled. 

2. The method for recalling a previous desktop state of 
Claim 1, wherein said step of detecting each occur- 
rence of a desktop event comprises: 

detecting input from a peripheral device interfaced 
to said data processing system which creates a new 
desktop state; 

detecting manipulation of said plurality of graphical 
objects displayed within said display; and 
detecting invocations of operating system functions 
and data processing programs. 

3. The method for recalling a previous desktop state of 
Claim 1, wherein said step of recording a state of 
said desktop comprises: 

storing within a data structure an entry correspond- 
ing to each desktop state, wherein each entry 
includes: 

an object identifier uniquely specifying a 
focused object among said plurality of graphical 
objects; 

an indicia specifying a parent graphical object 
among said plurality of graphical objects upon which 
said focused object depends; and 



.an input sequence that derived said focused 
object from said parent graphical object. 

4. The method for recalling a previous desktop state of 
5 Claim 3, wherein said step of returning said desktop 

state to a selected state preceding said current 
desktop state comprises: 

retrieving an input sequence stored as an entry 
within said data structure corresponding to a latest 

10 occurring anchor state whose associated graphical 
object is present within said current desktop state, 
wherein an anchor state is a desktop state whose 
associated focused object has a different object 
identifier than a graphical object associated with a 

is desktop state immediately preceding said anchor 
state; 

retrieving input sequences stored as entries within 
said data structure corresponding to desktop states 
prior to said current state which are dependent upon 
20 said anchor state; 

executing all of said retrieved input sequences in 
chronological order; and 

disabling refreshes of said display device until said 
selected desktop state is recalled. 

25 

5. The method for recalling a previous desktop state of 
Claim 1, wherein said particular input from a user 
comprises pressing a function key defined to invoke 
said step of returning to a previous desktop state. 

30 

6. A system within a data processing system for recall- 
ing a previous desktop state, wherein a desktop 
state comprises a dependence hierarchy and visual 
arrangement of a plurality of graphical objects rep- 

35 resentative of operating system functions and data 
processing applications that are displayed within a 
display device of said data processing system at a 
specified time, said system comprising: 
means for detecting each occurrence of a desktop 

40 event which creates a new desktop state; 

means, responsive to detecting an occurrence of a 
desktop event, for recording said new desktop state; 
. means, responsive to a particular input from a user, 
for automatically returning said desktop state to a 

45 selected state which occurred prior to a current 
desktop state by referencing said recorded desktop 
states, wherein all operating system functions and 
data processing applications available at said 
selected state are enabled; and 

so means for disabling refreshes of said display device 
until said selected desktop state is recalled. 

7. The system for recalling a previous desktop state of 
Claim 6, wherein said means for detecting each 

55 occurrence of a desktop event comprises: 

means for detecting input from a peripheral device 
interfaced to said data processing system which cre- 
ates a new desktop state; 

means for detecting manipulation of said plurality of 
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graphical objects displayed within said display; and 
means for detecting invocations of operating system 
functions and data processing programs. 

8. The system for recalling a previous desktop state of s 
Claim 6, wherein said means for recording a state 

of said desktop comprises: 
means for storing within a data structure an entry 
corresponding to each desktop state, wherein each 
entry includes: 10 

an object identifier uniquely specifying a 
focused object among said plurality of graphical 
objects; 

an indicia specifying a parent graphical object 
among said plurality of graphical objects upon which is 
said focused object depends; 

an input sequence that derived said focused 
object from said parent graphical object; and 

a status indicator, wherein said status indica- 
tor includes an indication that an associated entry 20 
may be deleted from said data structure. 

9. The method for recalling a previous desktop state of 
Claim 8, wherein said means for returning said desk- 
top state to a selected state preceding said current 25 
desktop state comprises: 

means for retrieving an input sequence stored as an 
entry within said data structure corresponding to a 
latest occurring anchor state whose associated 
graphical object is present within said current desk- 30 
top state, wherein an anchor state is a desktop state 
whose associated focused object has a different 
object identifier than a graphical object associated 
with a desktop state immediately preceding said 
anchor state; 35 
means for retrieving input sequences stored as 
entries within said data structure corresponding to 
desktop states prior to a current state which are 
dependent upon said anchor state; and 
means for executing all of said retrieved input 40 
sequences in chronological order. 

10. The system for recalling a previous desktop state of 
Claim 6, wherein said particular input from a user 
comprises an input generated by a user by pressing 45 
a particular function key. 
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